|
|
|
|
|
|
|
model. For instance, if you have a scenario that deals with the opening of an account for a customer with a valid Social Security number and good credit and checking account histories, your class model view would show only the members of the Account and Customer classes. All other classes would display only a name and possibly a single method that is meaningful to the context. |
|
|
|
|
|
|
|
|
Sequence diagrams literally show a sequence of interactions between actors and objects in your system. It's tempting to immediately associate sequence diagrams with data flow diagrams (DFDs), but they aren't the same. DFDs show only dimly defined paths of function calls. Sequence diagrams show the interaction between actors and objects for a given scenario, with focus on state changes and timing issues. |
|
|
|
|
|
|
|
|
Take a look at Figure 3.3. The sequence diagram from Day 2's Figure 2.7 is updated to include the two new classes (CreditHistoryInfo and CheckAccountHistoryInfo). |
|
|
|
|
|
|
|
|
Figure 3.3.
The sequence diagram has been updated to incorporate the new classes. |
|
|
|
|
|
|
|
|
Collaboration diagrams are similar to sequence diagrams, except they don't look as sequential and structured. Figure 3.4 shows how your sequence diagram would appear as a collaboration diagram. |
|
|
|
|
|
|
|
|
Collaboration diagrams aren't as popular with some OO camps as sequence diagrams. Nevertheless, in some situations, a collaboration diagram captures views of the system that better show method invocations on objects. The choice is a matter of preference more than science, generally speaking. |
|
|
|
|
|
